Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-059.TXT

Text File | 1992-06-03 | 41.8 KB | 1,056 lines

C.S.M.P. Digest             Sat, 25 Apr 92       Volume 1 : Issue 59

Today's Topics:

    Beta Testers
    MPW C++ and "force_active" pragma
    Finding out largest memory block in heap?
    Outlining default button in a dialog; FAQ list solution fails
    Electronic Publishing, That Is, Without Paper
    Info on Copyrights and Distribution
    Can anyone tell me about Prototyper?
    OOP version of ThinkC
    malloc() problem solved
    KCAP resource format?
    THINK C Problem
    Does anyone have any source code/file formats for graphics files


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Ramesh Chandak)
Subject: Beta Testers
Date: 10 Mar 92 11:34:19 GMT
Organization: GTE Laboratories Incorporated, Waltham MA

to all those who responded ( there were quite a few ) to my previous
posting regarding looking for beta testers, first of all : Thanx much
for your interest.  I shall get in touch with each one of you soon,  with
details of the product.

- - Ramesh Chandak
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ingemar Ragnemalm)
Date: 23 Mar 92 12:55:14 GMT
Organization: Dept of EE, University of Linkoping


BETA TESTERS WANTED:

A while ago, I put together a set of subroutines to deal with animation
of icon-sized sprites over a background. Some of you may have seen the
first result, the action game Slime Invaders. Though SI isn't a very
polished game, it tells something about what you can do with the toolkit.

Now I have polished things up, written smaller demo programs, separated
the game-specific code from the toolkit code, commented a bit more and
written a first draft of a manual. The working name for it is "Sprite
Animation Toolkit" (SAT). I intend to release it with full source code, free
of charge, asking only to get copies of programs using the toolkit.

The toolkit includes a package to produce asynchronous sound. This package
uses Sound Driver or Sound Manager depending on system version and whether
or not Apple Sound Chip is present.

Current limitations: black-and-white graphics, uses a "Classic-sized"
portion of the screen (but this is easily changed), only one window.
Sound package uses only one channel. The code is halfway object oriented,
but does *not* use Object Pascal.

Before releasing a package like this, I'd like to have some beta testers
looking at it, trying to make some hacks with it and comment on the manual.
So, if you have Think Pascal v4, and can answer any of the following questions
with "yes", I'd like to hear from you.

Ordinary testing:

- - Would you like to try making a game (or other program) using the SAT
toolkit? (Preferrably not Space Invaders or Pacman, I've made them already.)
- - Do you enjoy nitpicking on lousy manuals?

Help developing a better toolkit:

- - Do you have or are you capable and willing to make optimized routines for
drawing icons directly to the screen (without using QuickDraw) in assembly
language for addition to the SAT toolkit? (Relatively easy task for someone
who feels at home in Think C's inline assembly.)
- - Are you capable and willing to make a color version of the SAT toolkit?
(Hard task, I think. I'm stuck in the question of how to draw color icons
directly to the screen with correct colors.)
- - It shouldn't be too hard to hack SAT to *real* Object Pascal, for someone
who uses Object Pascal a lot. Would you like to do this?

For the record, related packages:
================================
I wouldn't have done this if there was something I knew of that would do the
job. However, there are two other packages that have a similar ambition:

- - Vector Animation Toolkit by Juri Munkki. (Currently in beta test.) Great
for making vector animations - but that is a totally different niche. Think C.

- - Offscreen Bitmap by John F. Hogg. (Also in beta test.) Uses Think C's
TCL library, and in color! Basically it is a set of routines for offscreen
pixmap management, as far as I'm able to tell. (The docs are very brief.)

While these packages are in color, SAT is so far only b/w, but it has more
support for game writing, including two complete (but of course very simple)
games with full source.

So, if you want to be a beta tester and/or contribute to the development of
this package, and intend to spend some time on it and mail me feedback,
please E-mail me at: [e-mail]

- --
Ingemar Ragnemalm
Dept. of Electrical Engineering         ...!uunet!mcvax!enea!rainier!ingemar
                  ..
University of Linkoping, Sweden         [e-mail]

---------------------------

From: [e-mail] (Sak Wathanasin)
Subject: MPW C++ and "force_active" pragma
Date: 12 Mar 92 16:11:55 GMT
Organization: Network Analysis Ltd

I've been trying to use the #pragma force_active ON/OFF directives described
in the ETO #6 release notes. Suppose I have a class TFooView that is instantiated
when a view is created at runtime. My reading of the ETO #6 release notes
led me to think that if I enclose all methods of TFooView inside
#pragma force_active ON/OFF directives, the linker would include all such
methods in the final build. I did this, and everything compiles, links etc,
but whenever I open the view in question, I get a "Can't open because TFooView
methods can't be found" message. I have to go back to using the gDeadStripSuppression
trick. What am I missing? Can someone post an example of its use?

Thanks in advance.

Sak Wathanasin
Network Analysis Limited

uucp:    ...!uknet!nan!sw
other:    [e-mail]
phone:  [phone]
snail:  178 Wainbody Ave South, Coventry CV3 6BX, UK

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 23 Mar 92 18:12:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Sak Wathanasin) writes:
>
> I've been trying to use the #pragma force_active ON/OFF directives described
> in the ETO #6 release notes. Suppose I have a class TFooView that is
instantiated
> when a view is created at runtime. My reading of the ETO #6 release notes
> led me to think that if I enclose all methods of TFooView inside
> #pragma force_active ON/OFF directives, the linker would include all such
> methods in the final build. I did this, and everything compiles, links etc,
> but whenever I open the view in question, I get a "Can't open because TFooView
> methods can't be found" message. I have to go back to using the
gDeadStripSuppression
> trick. What am I missing? Can someone post an example of its use?

Any pragmas which are inside a function statement won't work, because MPW C++
will try to move them outside the function scope. Why? Because the CFront
creates C code, and there are no guarantees where pragma statements inside
functions will suddenly end up. I.e. any possible 'force active' statements
have most likely moved.

So the compiler tries to move any possible pragma statements to the one and
only place it recognizes, the start of the function scope. This is documented
in the new MPW C++ documentation, out in May. The documentation will describe
each pragma in the C++ case, which work and which wont. Don't worry, pragma
segment works, pragma unused wont...

Cheers,
Kent


- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are private, and not owned by any company,
organization or group. Happy happy, joy joy!

---------------------------

From: [e-mail] (Jochen Meyer)
Subject: Finding out largest memory block in heap?
Date: 23 Mar 92 09:54:28 GMT
Organization: University of Oldenburg, Germany


I am writing a program that needs large buffers of unspecified size. For
this I need to get a memory block that is as large as possible. I know
that I could use MaxMem or something like that to get the size of the
largest block AFTER COMPRESSING THE HEAP.

What I need is a function that returns the size of the largest block that
can be allocated without compressing the heap.

This is of particular interest for me, since I wish to use temporary memory
and want to remain compatible to virtual memory. You know, compacting the
entire free memory if it is of several Megs size and is located on hard
disc seems to take quite some time (one minute or so).

Any answers are appreciated. Thanks!

Jochen
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 23 Mar 92 13:39:43 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Jochen Meyer) writes:

   I am writing a program that needs large buffers of unspecified size. For
   this I need to get a memory block that is as large as possible. I know
   that I could use MaxMem or something like that to get the size of the
   largest block AFTER COMPRESSING THE HEAP.

   What I need is a function that returns the size of the largest block that
   can be allocated without compressing the heap.

What's wrong with PurgeSpace ? It's in Inside Mac (IV, I believe)
and returns the max amount that "could" be available, without
actually making it available.

However, you might want to know how much is "safely" available ?
That's anorther story; the memory manager will only purge/move
blocks until it gets what it needs. The problem is, if you have two
8-byte blocks in the bottom of the heap, and you call NewPtr on a
meg, the memory manager will leap-frog the blocks after each other
all the way through the meg :-(

Since a purge is faster than a compaction, PurgeSpace may be better
than MaxBlock, though.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

---------------------------

From: [e-mail] (Dean Hickerson)
Subject: Outlining default button in a dialog; FAQ list solution fails
Date: 15 Mar 92 22:58:20 GMT
Organization: Computing Services, UC Davis

I've been trying to draw an outline around the default button in a
dialog box.  The FAQ list explains how to do this, by using a dummy
useritem to draw the outline.  But it doesn't work if the button's
height is too large:  That part of the outline that's within the default
button's rectangle doesn't get drawn.  For buttons with the usual height
of 20 pixels, there's no problem, because the outline doesn't intersect
the button's rectangle.  The problem first occurs when the height is 34,
and becomes very noticeable when the height is about 50.  If the height
is 56 or larger, the outline is cut into 4 separate pieces.

Here's part of the FAQL's routine for drawing the outline:

          diameter = (itemRect.bottom - itemRect.top) / 2;
          if ( diameter < 16 )
              diameter = 16;
          PenSize( 3, 3 );
          InsetRect( &itemRect, -4, -4 );
          FrameRoundRect( &itemRect, diameter, diameter );

If we just use 16 as the diameter, no matter how tall the rectangle is,
the problem goes away.  However, the outline then has squarer corners
than the button, which doesn't look great.

Has anyone else encountered this problem?  Why does it occur?  Is there
a good solution?

Dean Hickerson
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lloyd Lim)
Date: 19 Mar 92 09:30:05 GMT
Organization: U.C. Davis - Department of Computer Science

In article <[e-mail]> [e-mail] (Dean Hickerson) writes:
>I've been trying to draw an outline around the default button in a
>dialog box.  The FAQ list explains how to do this, by using a dummy
>useritem to draw the outline.  But it doesn't work if the button's
>height is too large [...]
>
>Here's part of the FAQL's routine for drawing the outline:
>
>          diameter = (itemRect.bottom - itemRect.top) / 2;
>          if ( diameter < 16 )
>              diameter = 16;
>          PenSize( 3, 3 );
>          InsetRect( &itemRect, -4, -4 );
>          FrameRoundRect( &itemRect, diameter, diameter );
>
>If we just use 16 as the diameter, no matter how tall the rectangle is,
>the problem goes away.  However, the outline then has squarer corners
>than the button, which doesn't look great.
>
>Has anyone else encountered this problem?  Why does it occur?  Is there
>a good solution?

You're having problems simply because the code is not calculating the
diameter correctly.  I never bothered double-checking the FAQ code because
I thought it was just handling the standard 20 pixel height case.

Here is some code that will look ok with any button size:
(using variable names similar to those above)

InsetRect(&itemRect, -4, -4);
diameter = ((itemRect.bottom - itemRect.top) >> 1) + 3;
PenSize(3, 3);
FrameRoundRect(&itemRect, diameter, diameter);

This is the same formula that I use in Default, the world's most anal
retentive default button outline drawing code.  If you really want to do
a prefect job, look at Default to see how to handle inactive buttons,
control color tables, System 7 dimming, and optimal display when straddling
monitors.  Disclaimer:  I wrote Default.  :-)

Another Macintosh programmer at U.C. Davis...  outstanding!!!
Feel free to send me e-mail about anything.

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616

+++++++++++++++++++++++++++

From: [e-mail] (Dean Hickerson)
Date: 23 Mar 92 22:34:35 GMT
Organization: Computing Services, UC Davis

In a previous posting, I said:

>  I've been trying to draw an outline around the default button in a
>  dialog box.  The FAQ list explains how to do this, by using a dummy
>  useritem to draw the outline.  But it doesn't work if the button's
>  height is too large:  That part of the outline that's within the default
>  button's rectangle doesn't get drawn.  For buttons with the usual height
>  of 20 pixels, there's no problem, because the outline doesn't intersect
>  the button's rectangle.  The problem first occurs when the height is 34,
>  and becomes very noticeable when the height is about 50.  If the height
>  is 56 or larger, the outline is cut into 4 separate pieces.

Thanks to Lloyd Lim ([e-mail]) my problem has been solved.  My
dialog's "Initially visible" bit was true and I was calling ModalDialog
without calling ShowWindow first.  Setting the bit to false and calling
ShowWindow makes the problem go away.

Now that I know what to look for, I see that Inside Macintosh actually
contains an explanation of this.  The description of the function NewDialog
(volume I, chapter 13) says that control items are drawn immediately, but
other items aren't drawn until after the update event (which NewDialog
generates).  So, to avoid drawing controls twice, the Dialog Manager calls
ValidRect for the enclosing rectangle of each control.

Thanks to Lloyd and the others who replied.

Dean Hickerson
[e-mail]

---------------------------

From: [e-mail] (Kent Borg)
Subject: Electronic Publishing, That Is, Without Paper
Date: 20 Mar 92 18:54:03 GMT
Organization: Camex Inc., Boston MA


I am interested in contacting people who are interested in "Electronic
Publishing".  But I mean *real* electronic publishing, publishing
where the content never hits paper.

Now that Powerbooks are popping up everywhere there is an audience
brewing.  For example: Camex (where I work) is not that big and is
mostly populated with Suns.  Until recently I knew of exactly one
notebook computer floating around here, some MS-DOS box.  Now I know
of three 170's (it has become a status symbol), a 100, and my personal
140.  I am sure there are more to come.  There was a co-worker asking
me about prices just a few minutes ago.

If you too have thought about the issues involved in real electronic
publishing: How to program it, how to design the user interface, how
to produce content, I am interested in hearing from you.


- --
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me

+++++++++++++++++++++++++++

From: [e-mail] (David Morgenstern)
Organization: San Francisco State University
Date: Mon, 23 Mar 1992 18:22:11 GMT

The Association of Research Libraries has a list (and now a book)
of electronically published Journals and Newsletters, and
Discussion Lists (listservs) and Interest Groups (Newsgroups). It's
called the Directory of Electronic Journals, Newsletters, and
Academic Discussion Lists. I think you can get a copy of the list
from Ann Okerson at [e-mail]

daviD
- --
*****     David Morgenstern (a.k.a. BMUG CheerLeader)     *****
*     CIS: 72030,1607   AOL: daviD eM   FAX: [phone]     *

---------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject: Info on Copyrights and Distribution
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Fri, 20 Mar 1992 23:04:19 GMT

Hello one and all. I have written 2 small Macintosh apps (well App and
Background App) that I would like to distribute as freeware (they play
sounds in the background, if you care)

Unforunately I do not know how to do this. Could somebody tell me?

Also, they are written in Think C. Symantec's licencing agreement sez that all I
have to do is have a copyright that covers their copyright on Think Cs run time
junk. However, I do not have such a copyright. I don't really want one, or know
how to get one either.

I have noticed that some things I have run in too (sorry, can't remember
any examples) have a "Portions Copyright Symantec [etc etc etc]".
Is this enough? Does anybody care about such things when the software isn't
commercial? Am I just being paranoid? :)

Ah well, thanks in advance.
- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

+++++++++++++++++++++++++++

From: [e-mail] (Thomas Aaron Insel)
Date: 20 Mar 92 23:48:34 GMT
Organization: University of Illinois at Urbana

[e-mail] (Daniel Norman Johnson) writes:

>Also, they are written in Think C. Symantec's licencing agreement sez that all I
>have to do is have a copyright that covers their copyright on Think Cs run time
>junk. However, I do not have such a copyright. I don't really want one, or know
>how to get one either.

>I have noticed that some things I have run in too (sorry, can't remember
>any examples) have a "Portions Copyright Symantec [etc etc etc]".
>Is this enough? Does anybody care about such things when the software isn't
>commercial? Am I just being paranoid? :)

Just put a line in your about-box and your version resource that says
"Copyright 1992 Daniel Norman Johnson.  Permission is hereby granted to
distribute unmodified copies of this software."  Your software will be
copyrighted, but it is clear that anyone can distribute it as freeware,
and Symantec will be happy.  You could spend $10 (or did they raise it
to $20) to register the copyright, but unless you plan on sueing someone
for copying your application, which sounds unlikely, it's a waste.
- --
Thomas Aaron Insel ([e-mail])
  s-mail: URH 227 Saunders, 906 W. College, Urbana IL 61801
  I speak for myself, and not for the State or University of Illinois.
  "We must not confuse dissent with disloyalty." -- Edward R. Murrow

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 21 Mar 92 06:28:48 GMT
Organization: The Portal System (TM)

> and Symantec will be happy.  You could spend $10 (or did they raise it
> to $20) to register the copyright, but unless you plan on sueing someone
> for copying your application, which sounds unlikely, it's a waste.

They raised it to $20.00.  I believe that you can still sue even without
registering.  However, you can only collect actual damages, which are
hard to prove (especially if you are giving it away!).  You might
not even be able to do this.  You can still sue to stop the infringement,
though.

With registration, you can collect statutory damages.  Basically, that
means that the Court will say, "Oh hell, it's hard to figure out how
much you were damaged.  Let's just call it $XXXX."

For more information, ask on misc.legal, misc.int-property, or
misc.legal.computing.  Or, if you can wait, I'll be entering law
school in September, so if you send me email in 1995, I'll be
able to provide a definitive answer then. :-)

---------------------------

From: [e-mail] (Brian D. Davison)
Subject: Can anyone tell me about Prototyper?
Date: 22 Mar 92 16:48:36 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


The subject says it.  I heard about a package called Prototyper in the
docs of a shareware game, and thought it sounded interesting - an
interactive interface builder for the Mac.  Linkable with Pascal, C,
etc.  Anyway, I can't find it in any of my Mac software catalogs or
magazines.  I even searched the net in case it was a shareware
product, but all I came up with was an old demo (v2.1) from 1989 or
so, which said it was written by George R. Cossey and published by
SmethersBarnes.  Its a decent demo, and I'm still interested, but no
address, phone number, price, etc.

Failing this, what other interface builing packages are out there?
I'd like something that would generate function outlines to control
the interface as well as set up the resources, etc.  I'm fairly
comfortable with ResEdit, but I'm not the only one going to use this
package and we'd like something that would generate some of its own
code.  No, I'm not asking Microsoft to port VisualBASIC to the Mac,
but if you've seen VisualBASIC, you've got an idea of what we're
looking for.
- --
Brian D. Davison                    Department of Computer Science
                                    Hill Center, Busch Campus
[e-mail]            Rutgers, The State University of New Jersey
!rutgers!paul.rutgers.edu!davison   New Brunswick, NJ  08903

+++++++++++++++++++++++++++

From: [e-mail] (Paul Robichaux)
Organization: New Technology, Inc.
Date: Mon, 23 Mar 1992 21:18:01 GMT

In <[e-mail]> [e-mail] (Brian D. Davison) writes:

>product, but all I came up with was an old demo (v2.1) from 1989 or
>so, which said it was written by George R. Cossey and published by
>SmethersBarnes.  Its a decent demo, and I'm still interested, but no
>address, phone number, price, etc.

 As far as I know, Prototyper has been replaced by Marksman. Same basic
 product, same developer, different name. I don't know if Marksman ever
 became available for sale.

>Failing this, what other interface builing packages are out there?
>I'd like something that would generate function outlines to control
>the interface as well as set up the resources, etc.  I'm fairly
>comfortable with ResEdit, but I'm not the only one going to use this
>package and we'd like something that would generate some of its own
>code.  No, I'm not asking Microsoft to port VisualBASIC to the Mac,
>but if you've seen VisualBASIC, you've got an idea of what we're
>looking for.

AppMaker, from Bowers Development, was recommended to me by postings in
this group. I've been using it for about two weeks and recommend it highly.
  Pros: can generate code for MPW/Think, Pascal/C, with/without MacApp/TCL.
        generated programs are Sys7-friendly
        generated code is readable and (so far) very stable
        has *lots* of interface options

  Cons: interface is sometimes counterintuitive
        can't switch a prototype between languages

It helps to do your whole interface first, because once you have AppMaker
generate code, if you make changes to that code, you'll have to reintegrate
it into the generated modules if you make changes.

Overall, though, AppMaker is solid and fairly easy to use. Two thumbs up.
(The only mail-order place that had it in stock was Mac's Place, for $217.)

And no, it's not Visual Basic.

- -Paul
- --
Paul Robichaux, KD4JZG          | NTI doesn't pay for my opinions, and NASA
[e-mail]   | doesn't know I have any.
         This message printed on recycled phosphors.


---------------------------

From: [e-mail] (James Kroger)
Subject: OOP version of ThinkC
Date: 22 Mar 92 19:47:16 GMT
Organization: none

1) Will ThinkC have full object oriented capabilities
in the forseeable future, or is MPW the only option?

2) What object oriented programming capabilities does ThinkC
currently lack?

Thanks for any info..

- --Jim

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 22 Mar 92 21:17:54 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ucla.edu> [e-mail] (James Kroger) writes:

   1) Will ThinkC have full object oriented capabilities
   in the forseeable future, or is MPW the only option?

Yes. Right about two years ago or so, when 4.0 came out.

   2) What object oriented programming capabilities does ThinkC
   currently lack?

No "OO" features (except multiple inheritance)

It has polymorphism, inheritance, data hiding, ... all the
things that there's no argument about being required for an
"OO" language. However, automatic constructors/destructors,
and statical scope for instances, are not in there.

As for what features Think C 6.0 will have, you'll have to
know that Symantec is VERY secretive about what they're
doing...

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Dent)
Organization: DIALix Services, Perth, Western Australia
Date: Mon, 23 Mar 92 11:08:11 GMT

I'd like to point out a couple of OOP features that Think C has that are
lacking in C++ and satisfy needs that people write some AWFUL C++ code to
work around (see comp.object for discussions).

Namely

member()
class_name()
new_by_name()

These three functions are very important for certain sorts of activity
(such as implementing persistence) and in particular the member() function
let's you implement similar features to parameterized classes (eg: containers
that sometimes DO have to know the class of their objects).

Andy Dent
A.D. Software - Mac, PC & Vax Programming and Training
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241
"It's amazing what one can accomplish when one doesn't know
 what one can't do" (Garfield)


---------------------------

From: [e-mail]
Subject: malloc() problem solved
Date: 22 Mar 92 20:22:09 GMT
Organization: New Jersey Institute of Technology


    Thanks to everyone who responded to my post asking for help with
malloc() and calloc(). The problem has been solved. Several people
suggested that I needed to #include <stdlib.h> which I was already
doing. A few others suggested that I make sure I was using two-byte ints
instead of four-bytes, but that's not an option in THINK C 4.0 which
automatically defaults to 2-byte ints. The real problem was diagnosed by
Phil Shapiro of Symantec (Cheers for Symantec and all other companies
that provide Internet tech support.) who guessed that I might be writing
beyond the bounds of a previously malloced array. That was apparently
the problem since after going through the previous malloc() calls and
paying more careful attention to how much space they were allocating,
the program ran perfectly.

    According to Phil writing beyond the bounds of an array may cause later
calls to malloc() to crash. That strikes me as funny since I'd suspect
the crashing to occur just about anywhere else, perhaps when I
accidentally overwrote something, or the memory manager moved an
important chunk of memory I thought I had locked down. My expectation
would be that a future malloc() would just grab some of what I thought
was the old malloc(), but I don't see why this would crash malloc()
itself. Nonetheless that's what was apparently happening. It also
appears that gcc 2.0 for UNIX is a lot more forgiving of this sort of
programmer mistake than Think C. If only there were a language that
simply let you dynamically dimension arrays (int array[x][y])  all this
would have been moot.
    Once again thanks to everyone for your suggestions and help.

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Date: 23 Mar 92 14:20:52 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] writes:
>    According to Phil writing beyond the bounds of an array may cause later
>calls to malloc() to crash. That strikes me as funny [...]

With memory overwrite bugs, a good sense of humor is often quite useful :-)

>My expectation
>would be that a future malloc() would just grab some of what I thought
>was the old malloc(), but I don't see why this would crash malloc()
>itself.

Probably because THINKL malloc has not only a "next malloc starts there"
pointer, but more sophisticated data structures in the heap itself.

>It also
>appears that gcc 2.0 for UNIX is a lot more forgiving of this sort of
>programmer mistake than Think C.

Unix mallocs tend to hand out malloced memory in larger chunks (buddy system,
for example, rounds the alloc request to the next higher power of two) and are
therefore more tolerant of slight overwrites.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "One fine day in my odd past..." -- Pixies, _Planet of Sound_

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 23 Mar 92 14:22:11 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
>     According to Phil writing beyond the bounds of an array may cause later
> calls to malloc() to crash. That strikes me as funny since I'd suspect
> the crashing to occur just about anywhere else, perhaps when I
> accidentally overwrote something, or the memory manager moved an
> important chunk of memory I thought I had locked down. My expectation
> would be that a future malloc() would just grab some of what I thought
> was the old malloc(), but I don't see why this would crash malloc()
> itself. Nonetheless that's what was apparently happening. It also

Well, you must remember that malloc() is using part of the memory
space you are allocating from to keep track of the memory allocation.
In fact, most malloc()'s put this data *right in front* of the memory
you are handed back. Thus, if you overwrite a piece of memory, you
are generally also overwriting the private information just in front
of the next allocated pointer. Thus, it follows that you would experience
the most failures on your next call to malloc() which would go flying
off into space tracker bad information about the memory space.

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

---------------------------

From: [e-mail] (Per Siljubergs}sen)
Subject: KCAP resource format?
Date: 22 Mar 92 22:06:19 GMT
Organization: Dept. of Informatics, University of Oslo, Norway

Inside Mac VI describes the KCAP resource, but it lacks info about
how it's used. Here is the rez format of the KCAP resource:

type 'KCAP' {
      rect;                             /* boundsRect of keyboard */
      rect;                             /* textRect, used by KeyCaps */
      integer = $$CountOf(MainArray);
      array MainArray {
         integer = $$CountOf(ShapeArray) - 1;
         wide array ShapeArray {
            point;       /* shapePoint, how are keys shaped? */
         };
         integer = $$CountOf(KeyArray) - 1;
         wide array KeyArray {
            byte;                 /* mask, but for what? */
            boolean or, and;      /* what is this operand used for? */
            bitstring[7];         /* virtual keyCode */
            integer;              /* dv, vertical offset of key */
            integer;              /* dh, horizontal offset of key */
         };
      };
};

Here are my questions:

How do I use the ShapeArray to shape none-rectangle keys?
What are the KeyArray's mask field used for?
What are the KeyArray's boolean (or,and) field used for?

Really hope anyone can help me with this.

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 24 Mar 92 04:04:45 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Per Siljubergs}sen) writes:
>Inside Mac VI describes the KCAP resource, but it lacks info about
>how it's used.

KCAP resources describe the key layout of Macintosh keyboards. They are
intended for use by the Key Caps desk accessory, but applications can also
take advantage of KCAPs for information about key arrangements. The program
kcapApp demonstrates use of the KCAP resource and is available in the Snippets
collection on the Developer CD and, presumably, on ftp.apple.com.

This is the format of the KCAP resource.

  rect, boundary for the keyboard (8 bytes)
  rect, appropriate for an editable line of text (8 bytes)
  integer, number of key shapes to follow (2 bytes)

  for each key shape:
    integer, number of points defining this key shape - 1 (2 bytes)
    for each point:
      point, opposite corner of a rect (2 bytes)

    number of keys of this shape - 1 (2 bytes)
    for each key:
      byte, modifier mask (1 byte)
      byte, OR/AND setting for modifier mask (1 bit) plus
        virtual keycode for this key (7 bits)
      integer, vertical offset from previous key (2 bytes)
      integer, horizontal offset from previous key (2 bytes)

The keyboard boundary rect may be offset from the origin. It can be realigned
with
    OffsetRect(keybdRect, - keybdRect.left, - keybdRect.top)

Each key shape consists of one or more rectangles.  The rectangles are defined
by a series of points, with one point specifying each rectangle.  The first
point is the opposite corner of a rectangle anchored at the starting pen
location for the key;  the next point is the opposite corner of a rectangle
from the last point; and so on.  The key shape is the union of the rects
defined by the points.

Note that a rectangle's point may be above or to the left of the previous
point.  To QuickDraw, this would define an empty rectangle, so the rectangle's
horizontal and/or vertical coordinates may need to be swapped before FrameRect
is called to add a rect to the key's region.

The pen is moved to the top left of the keyboard boundary rect before drawing
each group of keys of a given shape.  The pen location for each key is given
as a horizontal and vertical offset from the pen location for the previous
key.  The pen location for the first key of each shape is an offset from the
top left corner of the keyboard boundary rectangle.  The pen does not change
location when a key is drawn.

Use KeyTrans to determine the character to be drawn on the key.  The resource
provides a 7-bit virtual keycode, plus a mask for the modifiers to be passed
to KeyTrans.  If the most significant bit of the keycode byte is set, AND the
desired modifiers with the modifier mask.  If the bit is clear, OR the
modifiers with the mask.

The high bit of the virtual keycode byte indicates to KeyTrans the type of the
keystroke; before calling KeyTrans, clear the bit for a keydown, or set it for
a keyup. KeyTrans sets the state appropriately for dead keys only when called
for keydowns.

The global KbdType ($21E), a byte, contains the KCAP resource number for the
last keyboard used. Under System 6, KCAP resources are kept in the file "Key
Layout" in the System folder. Starting with System 7, KCAP resources are in
the System file. Alternatively, a machine's KCAP may be stored in ROM, where
it is available with the RGetResource call but cannot be viewed with ResEdit.

For more information on KeyTrans and KCHRs, see chapter 10 of Inside Macintosh
volume V, pages 14-23 and 14-96 of Inside Macintosh volume VI, and Macintosh
Technical Note #160. KCAP resources are discussed on pages 14-95, 14-100 and
14-101 of Inside Macintosh volume VI.

Grobbins        [e-mail]

Usual disclaimers apply.


---------------------------

From: [e-mail] (Jerome Chan)
Subject: THINK C Problem
Date: 22 Mar 92 19:47:47 GMT
Organization: Florida Tech, CP/EE Dept.

I keep getting an error when I do this:


class CMailer : public CApplication    {

    protected:
        Boolean    fAboutBox=false ;
}


- --
 The Evil Tofu


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 23 Mar 92 08:10:17 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@ee.fit.edu (Jerome Chan) writes:

   I keep getting an error when I do this:

   class CMailer : public CApplication    {

       protected:
           Boolean    fAboutBox=false ;
   }



Think C has no "friend" concept... And you can't initialize
members in the declaration. Remove fAboutBox = false ;

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Stefan Lindmark)
Date: 23 Mar 92 10:11:29 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Jon W{tte) writes:

   @ee.fit.edu (Jerome Chan) writes:

      I keep getting an error when I do this:

      class CMailer : public CApplication    {

          protected:
              Boolean    fAboutBox=false ;
      }



   Think C has no "friend" concept... And you can't initialize
   members in the declaration. Remove fAboutBox = false ;

In addition to this, you have to put ';' at the end of a class declaration.

- --
Stefan Lindmark, Mambootor Datakonsult
Smedbyvagen 40, 184 32 Akersberga, Sweden. Phone: [phone]

---------------------------

From: admiral.uucp![e-mail] (Nathan Neulinger)
Subject: Does anyone have any source code/file formats for graphics files
Organization: The Grid/Waffle BBS, 203-661-2873, -1279, -0450, -2967
Date: Sun, 22 Mar 1992 19:29:47 GMT

such as .GIF, or .PICT? Currently I am working in Think C, and need to
output an array of integers (2 dim), as an image, i have no problem
displaying it on the screen, but I need to be able to output it in other
formats such as MacPaint file, or a GIF file etc... In addition, once I
have the problem with exporting in black and white solved... I will need
to be able to export in 8 color, and 256 colors.

Also, Since I currently only own copies of Inside Macintosh vols 1 thru
3, would anyone care to share with me some sample code for
displaying/drawing in 256 colors? I have not problem displaying in 8
colors since that is covered in IM 1: QuickDraw...

Any assistance would be greatly appreciated...

Nathan Neulinger

- --
admiral![e-mail] (Nathan Neulinger) <uunet!admiral!halifax>
The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
(HST/V32) [phone] -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Mon, 23 Mar 92 15:27:14 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> admiral.uucp![e-mail] (Nathan Neulinger) writes:
>such as .GIF, or .PICT? Currently I am working in Think C, and need to
>output an array of integers (2 dim), as an image, i have no problem
>displaying it on the screen, but I need to be able to output it in other
>formats such as MacPaint file, or a GIF file etc... In addition, once I
>have the problem with exporting in black and white solved... I will need
>to be able to export in 8 color, and 256 colors.

PICT format is documented in Inside Mac volume V, and tech notes.
Basically, write the contents of a picture handle (created by
OpenPicture/ClosePicture) preceded by 512 bytes of zero to the data
fork of a file.  Same thing works for color pictures if you have Color
Quickdraw.  I believe the TIFF and GIF formats are both up on
sumex-aim.stanford.edu.  TIFF is a real bear to read, but not too hard
to write-- easier than GIF because you don't need a compressor, and
more portable than PICT.

>Also, Since I currently only own copies of Inside Macintosh vols 1 thru
>3, would anyone care to share with me some sample code for
>displaying/drawing in 256 colors? I have not problem displaying in 8
>colors since that is covered in IM 1: QuickDraw...

Too hard to explain in a message-- buy or borrow Inside Mac V.
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

---------------------------

End of C.S.M.P. Digest
**********************